Gaming machine having a secure boot chain and method of use

ABSTRACT

An electronic gaming machine (EGM) comprises a memory storing boot program code comprising first code; a central processing unit (CPU) arranged to access the memory and initiate a boot process by reading the first code from the memory; and a monitoring device having or with access to validation code and arranged to take at least one protective action if the first code does not match the validation code.

RELATED APPLICATIONS

This application is a continuation of co-pending U.S. application Ser.No. 11/777,180, filed Jul. 12, 2007, which claims priority from U.S.application Ser. No. 10/089,759, which claims priority as a nationalphase application of PCT/AU00/01192, which are herein incorporated byreference in their entirety, and relates to, and also claims priorityfrom, Australian Patent Application No. 2006903776, filed Jul. 13, 2006,Australian Patent Application No. 2006907047, filed Dec. 18, 2006, andAustralian Patent Application No. 2007903196, filed Jun. 14, 2007, whichare herein incorporated by reference in their entirety.

FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

[Not Applicable]

MICROFICHE/COPYRIGHT REFERENCE

[Not Applicable]

BACKGROUND OF THE INVENTION

The present invention relates to a gaming machine and a method ofprotecting an electronic gaming machine.

The development of an electronic gaming machine and program code to berun on gaming machines requires a great deal of effort. Further, giventhe nature of gambling regulations, there is a need for a high degree ofconfidence in the security of an electronic gaming machine. Accordingly,there is a need for electronic gaming machines that have a higher degreeof security.

BRIEF SUMMARY OF THE INVENTION

In a first aspect, the invention provides an electronic gaming machine(EGM) comprising:

a memory storing boot program code comprising first code;

a central processing unit (CPU) arranged to access the memory andinitiate a boot process by reading the first code from the memory; and

a monitoring device having or with access to validation code andarranged to take at least one protective action if the first code doesnot match the validation code.

In an embodiment the EGM is arranged to monitor reading of the firstcode by the CPU.

In an embodiment wherein the monitoring device is arranged to access thememory prior to the memory being accessed by the EGM.

In an embodiment, the monitoring device stores the validation code.

In an embodiment, the monitoring device is a field programmable gatearray (FPGA).

In an embodiment, the protective action is that monitoring device causesthe EGM to terminate or fail booting.

In an embodiment, the boot program code comprises second code and thefirst code comprises a hash algorithm and a pre-calculated hash of thesecond code, the first code being arranged such that when the CPUexecutes the first code, the CPU calculates a hash of the second codeand compares it to the pre-calculated hash and proceeds if the hashesmatch.

In an embodiment, execution halts if the hashes do not match.

In an embodiment, execution proceeds with execution of the second codeif the hashes match.

In an embodiment, the memory storing the boot program code is read only.

In an embodiment, the boot program code comprises third code comprisinga master private key signature of a pre-calculated hash of the thirdcode, and the second code comprises a master public key (MPK) and adecryption algorithm, the second code being arranged such that whenexecuted by the CPU, the CPU calculates a hash of the third code,decrypts the signature to obtain the pre-calculated hash, compares thetwo hashes and proceeds if the hashes match.

In an embodiment, the gaming machine comprises a further memorycomprising a signature of one or more external BIOS hashes, and thethird code is arranged such that the CPU verifies each external BIOShash before transferring control to any of the one or more externalBIOSes.

In an embodiment, the third code is arranged such that the CPU verifiesthe active boot partition on the active boot device by generating a hashof the boot partition and comparing it to a hash stored on the activeboot device before transferring control to the master boot record of theactive boot partition.

In a second aspect, the invention provides a method of protecting anelectronic gaming machine comprising:

storing boot program code comprising first code in a memory; andmonitoring initiation of a boot process in which a central processingunit reads the first code from the memory by comparing the first coderead by the CPU to validation code; and taking at least one protectiveaction if the read first code does not match the validation code.

In an embodiment the method comprises comparing the first code read bythe CPU to the validation code.

In an embodiment the method comprises comparing the first code to thevalidation code prior to the first code being read by the CPU.

In an embodiment, the boot program code comprises second code and thefirst code comprises a pre-calculated hash of the second code, and themethod comprises calculating a hash of the second code and comparing itto the pre-calculated hash and proceeding if the hashes match.

In an embodiment, the boot program code comprises third code comprisinga master private key signature of a pre-calculated hash of the thirdcode, the second code comprises a master public key (MPK), and themethod comprises calculating a hash of the third code, decrypting thesignature to obtain the pre-calculated hash, comparing the two hashesand proceeding if the hashes match.

In a third aspect, the invention provides an electronic gaming machine(EGM) comprising:

a central processing unit (CPU);

a memory storing boot program code; and

a removable memory device in data communication with the CPU and storingauthentication data comprising a public key,

the CPU arranged to access the memory and initiate a boot process byreading the boot program code from the memory, the boot processincluding authenticating at least one set of code to be executed by theEGM by retrieving and employing the authentication data from theremovable memory device.

In an embodiment, the authentication data is a public key. In anotherembodiment, the authentication data is a certificate comprising thepublic key and identity data.

In an embodiment, the at least one set of code comprises the code storedin a disk partition.

In an embodiment, the at least one set of code comprises operatingsystem code.

In an embodiment, the at least one set of code comprises code of aprogram.

In an embodiment, the CPU authenticates the at least one set of code byemploying the authentication data to authenticate intermediateauthentication data and employing the intermediate authentication datato authenticate the at least one set of code.

In an embodiment, the EGM is arranged to authenticate the removablestorage device prior to employing the authentication data.

Persons skilled in the art will also appreciate that the first and thirdaspects may be combined. In an embodiment, the monitoring device may beemployed to authenticate the removable storage device.

In a fourth aspect, the invention provides a method of protecting anelectronic gaming machine comprising:

storing boot program code in a memory;

storing authentication data in a removable memory; and

initiating a boot process in which a central processing unit reads theboot program code from the memory, the boot process includingauthenticating at least one set of code to be executed by the EGM byretrieving and employing the authentication data from the removablememory device.

Persons skilled in the art will appreciate that the first and secondaspects of the invention may be combined with the third and fourthaspects.

BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS

Exemplary embodiments of the invention will now be described in relationto the following drawings in which:

FIG. 1 is a perspective view of a gaming machine;

FIG. 2 is a schematic diagram of the main components of the gamingmachine of a first embodiment that relate to implementation of a secureboot chain;

FIGS. 3A and 3B show a flow chart of the secure boot chain in accordancewith an embodiment of the present invention;

FIG. 4 is a schematic diagram of the main components of a gaming machineof a second embodiment;

FIG. 5 is a flow chart of a method of a second embodiment;

FIG. 6 is a further schematic diagram of a gaming machine; and

FIG. 7 is a memory diagram.

The foregoing summary, as well as the following detailed description ofcertain embodiments of the present invention, will be better understoodwhen read in conjunction with the appended drawings. For the purpose ofillustrating the invention, certain embodiments are shown in thedrawings. It should be understood, however, that the present inventionis not limited to the arrangements and instrumentality shown in theattached drawings.

DETAILED DESCRIPTION OF THE INVENTION First Embodiment

Referring to the drawings, there is shown in FIGS. 1 to 3, a firstembodiment of an electronic gaming machine arranged to implement asecure boot chain during which a series of code portions are validated.

A gaming machine 10 is illustrated in FIG. 1. The gaming machine 10includes a console 12 having a display 14 on which is displayedrepresentations of a game 16 that can be played by a player. A mid-trim20 of the gaming machine 10 houses a bank of buttons 22 for enabling aplayer to interact with the gaming machine, in particular during gameplay. The mid-trim 20 also houses a credit input mechanism 24 which inthis example includes a coin input chute 24A and a bill collector 24B.Other credit input mechanisms may also be employed, for example, a cardreader for reading a smart card, debit card or credit card. A readingdevice may also be provided for the purpose of reading a player trackingdevice, for example as part of a loyalty program. The player trackingdevice may be in the form of a card, flash drive or any other portablestorage medium capable of being read by the reading device.

A top box 26 may carry artwork 28, including for example pay tables anddetails of bonus awards and other information or images relating to thegame. Further artwork and/or information may be provided on a frontpanel 29 of the console 12. A coin tray 30 is mounted beneath the frontpanel 29 for dispensing cash payouts from the gaming machine 10.

The display 14 shown in FIG. 2 is in the form of a video display unit,particularly a cathode ray tube screen device. Alternatively, thedisplay 14 may be a liquid crystal display, plasma screen, any othersuitable video display unit, or the visible portion of anelectromechanical device. The top box 26 may also include a display, forexample a video display unit, which may be of the same type as thedisplay 14, or of a different type.

As illustrated in FIGS. 2 and 3, the electronic gaming machine has acentral processing unit (CPU) 210. Boot program code forms a BIOS and isstored in a read only memory 220. Logically the boot program codeconsists of first, second and third code referred to hereafter as apre-boot-loader, a boot-loader and a BIOS-control-program.

The different portion of code contains components for different securityfeatures. Specifically: the pre-boot-loader contains a SHA 1 hash of theboot-loader; the boot loader contains a DSA master public key; and theBIOS control program contains a DSA signature of the BIOS controlprogram SHA 1 hash that is signed by the DSA master private keycorresponding to the DSA master public key.

As illustrated in respective FIG. 3, when the electronic gaming machineis reset, the CPU 210 of electronic gaming machine begins executing thefirst instruction of the pre-boot-loader stored in the BIOS 220. Themonitoring device 230 snoops every read access to the pre-boot-loader tothereby monitor reading of the pre-boot-loader by the CPU 305. Themonitoring device is implemented by a field programmable gateway andcontains a duplicate copy of the pre-boot-loader monitors access to theBIOS 220 that provides validation code that can be used to determinethat the pre-boot-loader is valid. The monitoring device verifies thatthe pre-boot-loader read out by the CPU matches 310 the validation copyof the pre-boot-loader stored in the monitoring device. If it does notmatch, the monitoring device halts operation in such a manner that thiswill ultimately cause the electronic gaming machine to fail booting 315.Thus, this ensures that the electronic gaming machine is running avalid, unmodified copy of the pre-boot-loader and hence that the code tocheck the validity of the boot-loader (as described in further detailbelow) is still present and will be executed by CPU 210.

The pre-boot-loader then copies the boot loader to random access memory270. The pre-boot-loader calculates a SHA 1 hash of the boot-loader copythat is held in RAM. The pre-boot-loader verifies that the calculatedhash matches the pre-calculated hash that is stored in thepre-boot-loader is described above. If following calculation of the hashthe boot-loader 320 it is determined at step 325 that there is no match325, the boot sequence fails 330. If there is a match, execution istransferred to the boot loader copy in RAM.

These set of steps ensure that the electronic gaming machine is runningan unmodified copy of the boot-loader and that the code to check thevalidity of the BIOS-control-program is still present and will beexecuted. The boot-loader runs from RAM to eliminate the risk ofremoving the boot program stored in the BIOS socketed device betweenverification and execution.

At step 335 the boot-loader calculates a hash of the BIOS controlprogram and copies the BIOS control program to RAM. The boot-loader thenretrieves a DSA signature from the BIOS-control-program and retrievesthe DSA master public key from the boot-loader. The boot-loader decryptsthe signature of the BIOS-control-program hash 340 and determines 345whether the hashes match. If the hashes fail to match booting is failed350. Otherwise the verification is successful and execution istransferred to the BIOS-control-program now stored in RAM. TheBIOS-control-program then seeks to verify any external BIOS 240 byreference to a signed table of external BIOS hashes 250. The CPU 220calculates a hash of each external BIOS 360. It decrypts the signedtable of external BIOS hashes 250 using DSA and the DSA master publickey contained in the boot-loader. Each external bios 240 is hashed andcompared to the now decrypted stored hash 365. Any external BIOSES notmatched are ignored at step 370. Otherwise control is transferred to theexternal BIOSes.

These steps ensure the electronic gaming machine is running a BIOScontrol program that has been signed by a master private key.

Next before the BIOS-control-program transfers control to the masterboot record of the active boot partition on the active boot device 260it verifies the active boot partition 375 by calculating a hash at theactive boot partition and verifying the hash against the DSA signaturestored on the active boot device using the DSA master key and DSA. If itdoes not match at step 380 the boot is failed at 385. Otherwise theprocess proceeds to load and execute the operating system at step 390.These steps ensure the electronic gaming machine is running an operatingsystem and system software that had previously signed by the DSA masterkey.

Persons skilled in the art will appreciate that the exact sequence ofstep may vary with a particular BIOS implementation but will in forcethat code passes a DSA signature verification step before it isexecuted.

Persons skilled in the art will appreciate that there maybe variationson the above boot sequence. For example, while the above embodimentemploys SHA 1 hashes and DSA signatures, other crypto graphic hashes andsignatures maybe employed. For example SHA 1-HMAC or RSA or a mixture oftechniques. Further, while we have described the use of RAM to avoid hotswapping cache memory could be used instead. There may also be someadditional steps carried out before software is executed. For example,the signature of system and game software components may be checked bychecking the entire disk partitions, directories or individual files.Such checks may be performed on demand, that is immediately prior to acomponent being loaded or in advance, that is prior to any componentsbeing accessed. Further in some instances it may be appropriate to checkcomponents with multiple signatures. This allows the loading of acomponent to be prevented if it has not be signed by all requiredparties which may include the manufacture of the gaming machine, aregulatory body or a third party developer.

Further, certificates rooted in the master public key may be stored withthe software components than the public keys. Herein the term“authentication data” is used to refer collectively to a public key, acertificate rooted in the public key, or other authentication dataincluding a public key.

Second Embodiment

FIG. 4 shows a second embodiment where the boot loader acquires a publickey from a removable storage device 410 such as an authenticated smartcard. In the remainder of FIG. 4 the same numbering is used as in thefirst embodiment. As discussed above, the boot loader can be used toverify a signature of system and game software either individually or byverifying the partitions on which they are stored. Accordingly, the key(or alternatively a certificate rooted in the public key) is retrievedfrom the smart card and employed to verify the signatures of theprograms or partitions. This allows the approximation of revocation ofpreviously signed program by not producing any smart cards with therelevant matching public key. This can be used in order to revokeincorrectly signed software before it is released. Further, it allowscontrol of the number of software images in active use.

A person skilled in the art will appreciate that while it has beendescribed above that the key stored on the smart card is used to verifysignatures of programs/partitions it can equally be used to verifycertificates of public keys that are in turn used to verify signaturesof programs/partitions.

In an embodiment, the credentials of the smart card are as establishedas earlier as possible in the boot sequence. For example by employingthe monitoring device to determine whether the smart card is valid in asimilar manner in relation to which the first code is processed above.Further, rather than relying on keys being encoded within the BIOS, insome implementations it may be desirable to retrieve a key or keysstored on the smart card to use in an earlier part of the boot sequencefor example, to verify the external BIOSes.

The process 500 is summarised in FIG. 5. Boot code is stored in memory510 and authentication data is stored in a removable memory 520. Theboot process is initiated 530 and authentication data is retrieved 540from the removable storage device. The method then involvesauthenticating 550 at least one set of code with the authenticationdata. The key from the smart card is then trusted until the next boot.

A person skilled in the art will appreciate that the removable storagedevice should be readily removable such as a smart card, USB token, orthe like.

Third Embodiment

In a third embodiment an Application Specific Integrated Circuit (ASIC)is used instead of the FPGA of the first embodiment as the monitoringdevice. As in the first embodiment, a boot memory contains the softwarethat is first executed by the CPU when it exits the reset state.Monitored memory (or hash checked memory) may also be used to storethose parts of the software that access critical security functions.

For example the ASIC may contain logic which can enable or disableaccess to cash payment mechanisms or auditing information. By puttingthe enabling switch in monitored memory it becomes possible to check thesecurity and authentication of the machine software before enabling ordisabling these features.

The boot program is checked by monitoring the CPU address and data buses611, as shown in FIG. 6. The ASIC 612, which monitors the buses 611contains a copy (in internal ROM) of the data in a portion 614 of theboot EPROM 613. When each word of data is fetched from EPROM 613 by theCPU a compare function 616 of the ASIC 612 first checks the address tosee if it is within that area duplicated in the internal ROM 617, and ifit is it then checks the data word that the CPU 615 is reading from theEPROM 613 against the appropriate word in the internal ROM 617. If thedata is the same then the CPU 615 is using the correct data from EPROM613, but if it is different then there is either an accidental error ordeliberate tampering. In this event the ASIC 612 takes appropriateaction which may include resetting the board and/or stopping otheroperations of the ASIC 612 internally.

In the an embodiment, the CPU address and data bus 611 are multiplexedtogether to reduce the number of pins used. Non-multiplexed buses mayalso be used.

The ASIC 612 may also contain logic to ensure that all memory locationsin the monitored memory are checked. If all locations within themonitored area are not checked when an inappropriate access is madeoutside the monitored area the check fails and the board locks up. Aninappropriate access is an instruction fetch or write cycle. Read cyclesare allowed, to enable the software in the monitored region to checkother parts of memory.

Two implementations of this are:

1. The address bus 611 is monitored and a register is used to store ascanned address value location. Whenever the address from the CPUmatches the value in this register the register is incremented. Thememory check is complete when the address register reaches the end ofthe monitored memory.

2. A signature of address accesses may be implemented. Each address iscombined in some form with the previous addresses to generate a fixedpattern. If the sequence of addresses is not the same as the originalstored pattern then the check fails. For example each address may becombined using a CRC algorithm with the previous address's althoughpreferably a more secure algorithm would be used.

Other implementations of monitored memory are possible:

1. Instead of checking the program as it is executed, the ASIC disablesthe EPROM and substitutes data to the CPU from its internal ROM. TheASIC thus acts as a memory device.

2. The ASIC reads the contents of the monitored EPROM area before theCPU exits the reset state and generates a cryptographic hash of thedata. Only if this hash matches a predefined value is the test passed.

3. Instead of checking the data as it is read from EPROM the ASIC readsthe EPROM contents and verifies it before allowing the CPU out of thereset state.

4. In a variation of the above two implementations, the ASIC allows theCPU to fetch the first word of a program after exiting reset, butinserts into this read cycle the verification reads from EPROM. It ismore difficult to tamper with this method as the cycles are notseparated clearly.

To provide further protection the monitored boot area may be read andmonitored at a later time after the test has passed and game software isrunning. This provides protection against some forms of tampering wheretampered memory is substituted for the original memory after the testpasses.

This scheme is most effective with as much functionality of the board aspossible implemented in the ASIC. One method of tampering is to replacethe entire ASIC, but if significant other functionality is included itbecomes a serious technical problem to redesign the ASIC.

Additionally the more critical the ASIC is to the functioning of theboard then the more difficult it is to get the board working again ifthe monitoring circuit disables the operation of the ASIC internally.

If the monitored memory test fails, the board and ASIC are typicallyreset to protect the gaming machine. Alternately program execution isallowed to continue but certain features of the ASIC are disabled,preventing the board from being used in its full capacity. This allowsthe software to display appropriate errors messages (especially in thecase of accidental memory errors), but effectively stops tamperinghaving any real consequence. In the case of gaming machines, certaincritical functions will also be inhibited such as software access tohardware meters 641, and inhibiting input and output of credit or thelike, such as by way of the credit card reader 642 or ticketreader/writer 643.

The internal ROM of the ASIC is expected to be small compared to thesize of the boot EPROM to reduce cost, although it could be the samesize. Alternately, and as described above, the cryptographic hash checkmay be embedded in the ASIC.

The size of the EPROM to be securely checked can be increased to thetotal size of the memory in the system without increasing the size ofthe ASIC internal ROM by embedding a checking program in the area ofEPROM that is checked by the ASIC. The checking program generates acryptographic hash over the entire memory area to be checked (which mayinclude the area monitored by the ASIC) and compares it to apre-computed value. If it matches then the entire region is assumed tobe unmodified. The method relies on it being difficult to tamper withthe data which is included in the hashed area while retaining the samehash value and that the ASIC monitors the program which generates andchecks the hash.

An advantage of this method is that the hash checking program isrelatively small, and can be expected to be smaller than a comparablesignature checking program. Therefore the size of the ROM in the ASICmay be reduced in size with this method.

A non-cryptographic checking algorithm may be used instead of the hashfunction, but algorithms such as checksum or CRC are relatively easy totamper with and are not preferred.

The data to be checked, either directly by the ASIC or included in thehash-checked region, may include program or data. The data may includetext messages such as “0 Aristocrat Leisure Industries” or “Thissoftware is authorized by Aristocrat Leisure Industries”.

Once the initial part of the boot memory has been authorized it can thensecurely check the rest of the memory in the system.

The monitored memory area may use a hash mechanism to check more memoryas described in the previous section or it may implement a digitalsignature check. The advantage with a digital signature check is inminimizing the amount of boot code that can never be changed withoutchanging the ASIC. The advantage of a hash check is that a hash issimpler and therefore requires less program space for monitored memorythan digital signature software.

Digital signatures are also used to authorize all other modules ofsoftware and data in the system, including system software and games.Each authorized EPROM or file has an associated digital signature whichis checked. If invalid signatures are found the data will not be usedand appropriate action will be taken, such as the machine locking up anddisplaying a message.

FIG. 7 shows a schematic of a memory map in which a first section of thememory space 721 is checked by the ASIC 612, a second part of the memoryspace 722 is checked by a hashed code and a third part of the memoryspace 623 is checked by digital signature. The memory space checked bythe checking software may include or exclude the area in which thechecking software resides. In the example illustrated in FIG. 7 thesignature checked memory space 723 does not encompass the memory space721 containing the checking software (i.e. the space monitored by theASIC) but the hash checked memory space 722 does encompass the memoryspace 721.

In an embodiment, continuous monitoring of the authenticity of softwareprovides extra security. The memory contents are periodically recheckedto ensure that changes have not occurred.

Continuous monitoring requires a method of getting the CPU to startexecuting software within the monitored (or alternately hash checked,although this is not as secure) memory area.

Once the CPU starts executing software within this secure area it canagain perform authorization checks of the system as required. A watchdogtype monitor is implemented in the ASIC which must be accessedperiodically from software executing within the secured memory areaotherwise the ASIC will force the system to shutdown. This transfer tosecure area may be simply by software jumping to an address periodicallyor caused by an interrupt from the ASIC.

The ASIC is able to detect that software is executing from the monitoredarea. The method used depends on the processor implementation. Forprocessors which support identification of external bus cycles aninstruction fetch from a predefined address is used. For processorswithout identification of bus cycles and also without internal cachememory a sequence of memory accesses is detected that may only begenerated by software executing within the monitored area. For CPUwithout bus cycle identification and also with cache it may not bepossible to guarantee detection of monitored area software execution.Tampering could take place by execution of software within the cache sothat external cycles appeared to be the correct software accesses.

An alternate method of guaranteeing execution within monitored memory isto periodically reset the CPU. In this implementation the CPU is able tobe reset separately from the rest of the system. Prior to being reset,the CPU saves it's operational state in memory for restoration after theauthentication checks have been completed. After the ASIC has reset theCPU then the CPU must be executing from monitored memory. A flag in theASIC indicates the cause of the reset so the CPU knows whether toexecute cold start reset code or continuous monitoring code. While theCPU is in the reset state the ASIC checks the state of the relevant pinsto ensure that the CPU actually has been reset. In the preferredimplementation the ASIC contains a timer which is initialized after eachreset and which locks up the board when it reaches a predefined count.The timer would require that the CPU be reset every five minutes forexample. Periodically and at least less than every 5 minutes the systemsoftware saves the system state and instructs the ASIC to reset the CPUand also timer. The system software can choose a point in it's operationwhere a slight delay while the CPU resets is not noticeable. Alternatelythe ASIC generates an interrupt periodically which the system softwareresponds to by saving the CPU state and then the CPU resets.

These authentication checks are as described in the rest of thedocument. The authentication check can be divided into a number of theseexecution periods to divide the CPU loading over time. In this case thecheck software may need to store information between the periods (suchas the last memory location checked). Although this data may be storedin RAM, it is accessible by any software running on the machine andcould be tampered with. Preferably the ASIC implements some RAM that isonly accessible by software running within the monitored memory area.

One possible method of tampering is to find start execution code withinthe monitored area, which was not intended as a start address for theroutine and which has side effects unintended by the system programmers.

This side effect would access the flag in the ASIC without running thesecurity check. One method of preventing this is to implement an addresssignature check as described for “ASIC Monitored Memory”. A significantsection of code must be executed correctly for the signature to becorrect and it must be from the correct address. Many other methods arepossible.

One method of tampering with the system is to allow the correct bootcode to be executed after reset and during authentication, then at anappropriate point map into the program memory a new section of code(e.g. in hardware swap EPROMS with a multiplexer circuit). This memorymay be automatically mapped in an out of memory space depending on whereprogram execution is being performed. The authentication check reads theoriginal data and passes, but when control is passed elsewhere adifferent program is executed. To prevent this attack, at a random timethe ASIC reads from the CPU data bus the instruction fetched frommemory, and stores it in a register together with the address from whichit was read. When the periodic authentication check is performed itreads these registers and compares them with the data it reads from thesame location. If the data is different then tampering has taken place.This test will eventually, at a random time, detect tampering. To speedup this test more than one data location may be sampled. Because it maytake some time before tampering is detected it is preferable that whentampering is detected this information is stored so that the machinecannot be used until this condition is acknowledged by the operator andfixed. It should be stored in non-volatile memory, and preferablynon-erasable memory.

True random number generation is not usually feasible in an ASIC andinstead pseudo-random numbers are typically used instead. Thepseudo-random number may be randomized further by combining it with someexternal information, such as the contents of the data or address bus.

An alternate method is to use DMA or bus mastering by the ASIC toautomatically read the contents of memory and verify the data. Thismethod is most suitable for the boot code, as the complexity of thedesign for more equivalent functionality to that easily achieved insecure software to very high—although it is possible.

These methods allow the verification of programs and data in boot memoryand which is not possible to tamper with by simply changing the programmemory.

An advantage of these security systems is that non-volatile re-writablememory can be used to hold the boot program. Even if tampered code weresomehow loaded into memory the security mechanisms would prevent itbeing executed.

An advantage of Application Specific Integrated Circuit (ASIC) monitoredmemory and hash checked memory security mechanisms is that relativelysimple logic is required in the ASIC and the rest of the securitymechanism is in software. If the entire mechanism were placed in theASIC it would be far more complex, costly, less flexible and take longerto design.

Fourth Embodiment

The above methods may also be supplemented by a further method thatinvolves embedding into the authorized software a message which makes alegal statement about that software and it's ownership or authorization.Such a statement might include a text message such as “This Software IsAuthorized By Aristocrat Leisure Industries” or “© Aristocrat LeisureIndustries”.

The authentication hardware or software expects that the message beembedded in the program/data it is authenticating. If the message is notpresent in the appropriate place the authentication test fails and thedata/program is not used. Unlike digital signatures this method istechnically easy to cheat, by embedding the message, but provides legalrecourse to the manufacturer if it is detected. Digital signatures aretechnically difficult but potentially legally weak. The two methods maybe combined to provide both legal and technical security.

Referring to FIG. 6, components of a gaming machine are shown. After thesecure boot routines held in the EPROM 613 have been verified asdiscussed below, these routines can be used to load programs from a massstorage system 631 such as a hard disk drive 633 andcontroller/interface 632. Other mass storage systems can also be usedsuch as a CD or DVD ROM drive, a floppy disk drive or ZIP™ drive. Themass storage system 631 may be local to the CPU and read via the buses611, or may be remote and data sent to a writable memory local to theCPU over a network. The program will be loaded from the mass storagedevice into RAM by a loader program, which is preferably held in EPROM613, but could also be held in a ROM associated with a logic circuitsuch as the ROM 617 of the Application Specific Integrated Circuit(ASIC) 612. In alternative embodiments, the ASIC 612 may be replaced bya Field Programmable Gate Array (FPGA). As the program is read from themass storage device 631, the loaded code is scanned for a predeterminedtext string embedded in the code such as “© Aristocrat LeisureIndustries”.

The scanning may either be performed in software by a routine in theloader program, or alternatively the ASIC 612 may be programmed to scanthe data flowing over the buses 611 and locate the text string. Inanother embodiment, a hard wired scanning circuit can be connected tothe busses 611 to scan for the string. This method of verification maybe used instead of a hash code or encrypted signature, but in thepreferred embodiment is used as well as an encrypted signature or hashcode verification method.

Once the loaded program has been verified, the embedded text string willbe displayed on a display device 634 such as the video display screen ofa gaming machine on which the program is running, such that visualconfirmation of the validation is provided. This display function isperformed by the loaded program thereby also enabling detection offraudulent use of software on other manufacturers hardware. The loadedprogram also performs internal consistency checks to prevent alterationor deletion of the text string.

Fifth Embodiment

The Multigame authorization system allows games to be used only on thesystem for which they are authorized. The System program confirms theauthorization of the game before it is allowed to be used.

Preferably game authorization comprises one or more of the followingsteps:

-   -   The header section of the game memory is checked to confirm that        it is an appropriate game (e.g. not another system EPROM        incorrectly used, has valid version numbers, etc).    -   The game header is checked for the legal authorization message.    -   The game header checksum or CRC is checked to ensure memory        integrity.    -   If the games are digitally signed, then the digital signature(s)        are validated.    -   The authorization of the game to run on this particular gaming        machine is checked.

If the authorization fails the gaming machine may either continuewithout allowing that game to be used, stop and ask the operator toremove the game from the machine, or run that game only in demonstrationmode.

Preferably each gaming machine contains a unique identification numberwhich the CPU can read and use as part of the authorization code.

This can be implemented using a Dallas Semiconductor serialidentification chip (e.g. D5240 1).

If the authorization fails games may run in a limited mode and displayan appropriate message on the screen. The limited mode may prevent themachine accepting or paying out money or updating critical auditinginformation.

Sixth Embodiment

An EPROM authorization message is created by applying a digitalsignature to a message composed of the unique Game Identifier, a uniqueGaming Machine identifier and any usage restrictions that may berequired (e.g. date restriction on game operation). The signature isgenerated in a secure environment and sent to the gaming machine whereit is stored in non-volatile memory for later use.

The secure environment may be:

-   -   Within a smartcard. A service technician or operator may        authorize the game to run on the machine by connecting the        smartcard to the machine where the game is installed. To limit        accidental or deliberate fraud the smartcard preferably contains        a limit on the number of games that can be authorized. The        smartcard may be inserted into a special purpose interface on        the gaming machine, a general purpose interface such as is used        for player marketing cards or via a PC and communication        interface (e.g. RS232 or Ethernet) with a smartcard reader.    -   The gaming machine supplier may generate the authorization key        and supply it to the service technician/operator for entry into        the gaming machine.    -   The authorizations may be encoded into a removable EEPROM chip        which is supplied to the operator with the new games.

Persons skilled in the art will appreciate that various of the aboveembodiments may be combined with other embodiments or modified toincorporate features of other embodiments.

These and other variations will be apparent to persons skilled in theart and should be considered as falling within the invention describedherein.

1. An electronic gaming machine (EGM) comprising: a central processingunit (CPU) arranged to initiate a boot process using first code; and amonitoring device having access to validation code and arranged to takeat least one protective action if the first code does not match thevalidation code, wherein the CPU executes the first code, the CPUcalculates a hash of a second code and compares the calculated hash to apre-calculated hash and proceeds if the hashes match; and wherein whenexecuted by the CPU, the CPU calculates a hash of a third code, comparesthe hash to a stored hash of the third code, and proceeds if the hashesmatch.
 2. An ERM as claimed in claim 1, wherein the EGM is arranged tomonitor reading of the first code by the CPU.
 3. An EGM as claimed inclaim 1 wherein the monitoring device is arranged to access a memoryprior to the memory being accessed by the EGM.
 4. An EGM as claimed inclaim 1 wherein the monitoring device stores the validation code.
 5. AnEGM as claimed in claim 1 wherein the protective action is that themonitoring device causes the EGM to terminate or fail booting.
 6. An EGMas claimed in claim 1 wherein execution halts if any of the hashes donot match.
 7. An EGM as claimed in claim 1 wherein a memory stores thefirst, second, and third codes, and wherein said memory is read only. 8.An EGM as claimed in claim 1 further comprising a further memorycomprising a signature of one or more external BIOS hashes, and thethird code is arranged such that the CPU verifies each external BIOShash before transferring control to any of the one or more externalBIOSes.
 9. An electronic gaming machine (EGM) as claimed in claim 1further comprising: a removable memory device in data communication withthe CPU and storing authentication data comprising a public key, the CPUarranged to access the memory and initiate a boot process by reading theboot program code from the memory, the boot process includingauthenticating at least one set of code to be executed by the EGM byretrieving and employing the authentication data from the removablememory device.
 10. An EGM as claimed in claim 9 wherein theauthentication data is a certificate comprising the public key andidentity data.
 11. A method of protecting an electronic gaming machinecomprising: initiating a boot process; reading first, second, and thirdcodes from a memory in response to initiating the boot process;calculating a hash of the second code; comparing the calculated hash toa pre-calculated hash of the second code; in response to the calculatedhash of the second code matches the pre-calculated hash, calculating ahash of the third code; comparing the calculated hash of the third codeto a pre-calculated hash of the third code; and in response to thecalculated hash of the third code does not match the pre-calculated hashof the third code, taking at least one protective action.
 12. A methodas claimed in claim 11, comprising comparing the first code read by theCPU to the validation code.
 13. A method as claimed in claim 11comprising comparing the first code to the validation code prior to thefirst code being read by the CPU.
 14. A method as claimed in claim 11comprising: storing authentication data in a removable memory; andinitiating a boot process in which a central processing unit reads theboot program code from the memory, the boot process includingauthenticating at least one set of code to be executed by the EGM byretrieving and employing the authentication data from the removablememory.
 15. A method as claimed in claim 14 wherein the authenticationdata is a certificate comprising the public key and identity data.